Volume 2

Issue 3

September 2005

Tools and Technology The marriage between dynamic and static web content Ted Spencer Web Content Management Consultant ted@tedspencer.ca Many organizations have independent designs and systems for their dynamic and static web content. But the trend right now is to find a way to give dynamic sites more flexibility, rounding out their transactional capabilities with a more content rich user experience that can be found on static html sites. In this article, Ted Spencer, a web content management consultant, describes how to adapt traditional transactional web site designs to deliver html site flexibility, and facilitate reuse across static and dynamic pages. Introduction Large organizations such as financial institutions often base their transactional sites on coded web pages (web pages that are compiled code and execute business logic/display logic) and their marketing sites on flat html. From a content perspective, coded pages sew together small snippets of text and links to wrap around your account data and produce the html that hits your browser. However traditional coded web pages just aren't cutting it these days. In fact, many organizations want their transactional sites to become more content rich, and in the process reap some of the benefits that their static marketing sites have had for years. They want the flexibility to add, remove, and change content quickly, and at the same time be able to reuse that content across both dynamic and static pages. But along with a merging of abilities comes a dilemma - the common dynamic and static approaches allow for elements of reuse within each approach, but not across them, so a unique approach needs to be developed to bring the two designs together. Better defining the scope of change Content architects may not be overly concerned with how a content architecture is "absorbed" by an end application, however, the limitations and benefits of the end application do put huge pressures on content design. And because of this, many organizations view a universal content architecture across both transactional and marketing sites as almost impossible. To illustrate the pressures imposed on dynamic content design, let's take a look at the present design of many transactional sites at financial institutions. On these sites, dynamic web pages are created from compiled web pages. One popular example is java server pages (or `.jsp' pages) that you'll see at the end of your URLs. These coded pages often retrieve their content elements such as text, links, and images directly from set relational database fields or from name value pair-based fields in files. Storing content directly in small fields has created a precedence within the content design of these sites; the coded pages organize most of the content, whether the page has lots of dynamic content or not. The pages are responsible for layout, table generation, wrapping html tags around text elements and paragraphs, and even link generation. All of the code required to piece together a page from small chunks of text is cumbersome, and this is where straight html pages still satisfied a need for flexibility for so many years and made separate marketing sites so popular. Straight html can be changed quickly without any real programming, and its flexibility is close to limitless. This is why many companies will still argue, "well, who cares - our marketing site allows our customers to find static content (such as new products and company news), and our transactional site allows them to see their balances online. Customers are getting what they need!" But companies with this point of view soon hit a road block when they want to start enriching the user experience on their sites; the dynamic pages need to have the flexibility of the static pages to change content rapidly, and the static pages need to have dynamic capabilities to accommodate for dynamic navigational components or customized user experiences. On top of that, once the company is mature enough from a content management point of view, they realize the downfalls of not sharing their content for common product descriptions, company communications, or online help across these page types. Picking a content design to pull it all together To pick a content design to support the sharing of content across pages, you need to figure out what exactly you are starting with, then decide where you want to go with it. On transactional sites, the responsibility for pulling the content together is solely placed on the coded page. This is where the big limitation of many transactional sites lies, and is a good start for the initial focus of any design that tries to create greater layout and content flexibility for a dynamic site. Designing the base content archetypes Here's an overview of how your design can get around the limitations of traditional coded pages: Keep the small elements that are the cornerstone for the original transactional site design You'll still need these small text, link, and image elements because you will need to display small snippets of text on pages, depending on what the backend systems see. For example, you'll always need the flexibility for the page to conditionally display a link, such as an additional description or a note about a transaction. At a minimum, these small elements will include: Text (one or more words that could contain links or images.) Links Images These small elements should also be based upon an xml schema, the rationale for which will be discussed later on. Introduce a more flexible content type based on xhtml Create a content element that has all the flexibility you're looking for, and at the same time, structure. How? By using xhtml, which quickly introduces the flexibility of html into your transactional site. An area of the page no longer needs to be defined just as a paragraph, text item, link item, etc. It is actually considered any valid representation of xhtml. Then just like a normal html page, that area can grow, shrink, or incorporate any valid xhtml tags it likes. But why are we using xhtml? Because of the ability it gives you to enforce content element reuse. Customize your new xhtml content type Create your own schema around these xhtml content types, or blocks of xhtml, so that you can enforce reuse of certain content archetypes. For example, if you want to ensure links and images are reused across the site, enforce this in your own customized xml schema, indicating that links are not allowed explicitly in the xhtml. Instead, allow for a reference to a link to be used. When that xhtml block is pulled from the repository by an extraction application, the link gets resolved. This customization step is the real key to enforcing reuse at the element level in the system. Above all you can ensure that links are properly reused across your static and dynamic pages. Adding structure to organize content The next step after setting up your primary archetypes is to organize them outside of the coded pages. This allows your server side code to focus more on what it pulls from the backend, rather than on what its doing to weave together the webpage. References You'll need some way to reference objects within other objects. As described in the link example above, this is the key to enforcing reuse in the system and not having just a million instances of the same link all over your transactional site. Updating that link would become a nightmare. These references should be allowed to exist within your xhtml block schema, and also potentially exist within text and link elements as well. There would likely be references for each of the major archetypes Xhtml block reference Text reference Link reference Image reference In addition, a mapping of references to archetypes will be needed to keep track of what references are allowed in each given archetype. Mapping is necessary, since the interrelationships can get intricate depending on how you want to enforce or not enforce reuse on your site. Groups Grouping is one of the most elemental tasks of making associations, in any type of system. By creating a generic content structure, you open the door to using the structure in many ways. Individual xhtml blocks can be grouped together to form pages, links can be grouped together to form left navigations, and other xhtml objects can be grouped to constitute your standard headers and footer. The coded pages can pull in these groups of xhtml onto their pages very easily - and the code plays no role in formatting or display. The coded pages just pull a set of groups and display them sequentially on a page. But how will the pages know which groups to pull? Pages Your coded pages get the groups by referencing their own instance of a page content type. Just as your archetypes form the lowest level basis for your content, pages will form the highest level, and at the very least will only need to contain groups. These groups can be classified or labelled within the page content type in terms of header, footer, main page content, left navigation etc., making it very simple for a coded page to pull in the group to the appropriate area on the page. Getting the old coded page to work with the new design Coded pages will now call their respective page content objects and reference a specific labelled group, which will in turn retrieve the large xhtml blocks that are pointed to in each group. The page won't apply any logic when it pulls a group. And that's the key to this design. If a page does not require any coded logic or data retrieval from a backend system, then it just goes to its respective page, pulls in all the appropriate groups of xhtml blocks, and renders the page. When the coded page needs to add in a table etc, it will apply its own logic to that small area of the page, pulling in the smaller text elements or link/image elements as needed, retrieving the base archetype from the repository directly. The coded pages and the repository now have almost everything they need. They can choose whether to apply logic or not, have the flexibility of xhtml through the newly designed content types, and through the repository's customized schemas for xhtml blocks and smaller schemas attached to the base archetypes, the system can reliably enforce reuse. With this design, reuse can now exist across your static and dynamic pages since all content elements are driven out of a single repository and page design, not two siloed systems. You've got the perfect marriage now - with a few base elements - and a bit of structure. Where to place this content design Many possibilities exist for storing a content design based on xml. The xhtml block concept definitely requires it, and it's a natural fit to choose a database or repository with a strong support for xml. Xml repository options include native xml repositories or xml enabled relational databases such as Oracle 10G or SQL Server 2005. Xml-enabled relational databases can offer developers easier access to traditional table creation which many developers are comfortable with and can use quite easily to create a lightweight repository application to add/edit/delete/promote content from. Many organizations have been reluctant to invest in large scale CMS applications, and xml-enabled relational databases give many options for home grown solutions. Conclusion The cornerstone to a successful marriage between dynamic and static content on a single website is in letting the code pull the data and the repository organizing the content. Increasing a dynamic site's flexibility by adding a content type based on xhtml is a good first step. Then, giving responsibility to a repository for weaving together your content instead of coded pages will solve traditional flexibility limitations. Through this method a hybrid site will have a way to reuse content across dynamic and static pages since content will now reside in the same repository in the same format, and flexibility will be high since the transactional site now has almost all the attributes of xhtml.